OpenFOAM-v2506

OpenFOAM-v2506のAllrunの結果を公開した。総ケース数492（490）、使用ディスク容量：1028GB（約1TB）、総計算時間：約20日（20日）であった。かっこ（）内数字はv2412のもの。

計算開始：2025年7月8日9時5分　/　計算終了：2025年7月28日18時39分

Table of Contents

ケースサマリー

基本的に、先の記事に記した方法で、ほぼログ解析まで問題なく実行できた。実行エラーしたケース、残された手作業項目等についても、簡単に取り纏めておく。

新規追加されたケース（v2412比）

これらのケースにはAllrunは含まれないので、普通にtutorialsケーストップレベルのAllrunを実行すると単体実行されてしまう。しかし、decomposedParDictが同梱されているので、foamRunTutorial コマンドで実行すると並列計算されることになり、本来は並列計算を想定したケースと考えた方が良さそうである。

そこでこれらのケースには並列計算用のAllrunを同梱して実施している。

同様のケースは他にもあるが、総計算時間に対する寄与度の大きいこれらのケースを対象にしたということで、今後増えるかもしれない。

ログファイル（testLoopReport, logs）中に”ERROR”の出力があったもの

“ERROR”出力は無かったが、計算が発散終了していたもの（v2412以前でも同様）

ｖ2412ではエラーだったのが解消された

（注1）Allrunでは正常に計算できていた（ERRORはAllTest）

（注2）ERRORが出ること自体は問題無い

  • Allrun実行前
    • チュートリアルリスト作成
    • プロセッサ数が不足するケースでのdecomposeParDict変更
    • AllTest実行し、ERRORケース確認
  • ログ解析スクリプト実行前
    • incompressible/pimpleFoam?laminar/cylinder2D ケースの、log.blockMesh.main をlog.blockMesh に変更
  • ログ解析スクリプト実行後
    • ケース名変更
      • combustion/XiFoam/RAS⇒combustion/XiFoam/RAS/moriyoshiHomogeneous
      • compressible/sonicLiquidFoam⇒compressible/sonicLiquidFoam/decompositionTank
    • ディスクスペースの重複カウント修正
      • IO/fileHandler
      • compressible/rhoPimpleFoam/laminar/helmholtzResonance

データベースのグラフ化例

別記事で記した通り、上記データベース化されたデータはバックボーン（phpMyAdmin）で動的にグラフ化できるようになっているが、現在のところ閲覧者が動的にグラフを作成する仕組みまでは出来ていない。HP管理者が、本結果（OpenFOAM-v2506）を中心に様々な観点で作成したグラフをいくつか紹介しておく。

チュートリアル数の推移

使用したSQL構文

使用したSQL構文

使用したSQL構文

 

使用したSQL構文

使用したSQL構文

v2412のデータは、v2412のまとめ記事のデータと異なっているのは、一部のlagrangianのケースで、単体計算していたのを並列計算でやり直している

使用したSQL構文

 

使用したSQL構文

使用したSQL構文

上図で、変化のなかったライン（x1）から大きく乖離したケースについて番号付きの角矢印記号を付しておいた。以下の項目中の行頭（）中の数字はその番号に併せてある。また、赤字で記したものは、計算時間が短くなったもので、それ以外は長くなっている。

計算が正常終了（v2412では異常終了）

計算が異常終了

実行時並列数が異なる

同上、Allrun変更（単体計算⇒4並列計算）

clockTime異常（exeTimeは変化なし）

並列数の設定ミス

その他原因不明

後のまつり（データ整理してからわかった事）​

今回の計算サーバーはコア数が16であるので、並列数「16」以下となるようsystem/decomposeParDict を変更して実行したが、一部に設定ミスがあったので、次回の参考とすべく、ここに記しておく（v2412の記事にも記してあったが、またやらかしてしまった）。

IO/cavity_partProfiling

デフォルトでは、decomposeParDict が以下に示すようにnumberOfSubdomains 「20」( Np=20 ）となっており、これを 「8」 として実行したが、エラー終了してしまった。

				
					numberOfSubdomains  20;
method              scotch;
coeffs
{
    // Divide into 20/10=2 nodes
    domains (10);
    // Inside a node the communication weight is 1% of that inbetween nodes
    domainWeights (0.01);
}

method が scotch となっていたので、この numberOfDomains 数字だけを変えれば良いだろうと早とちりした。よく見れば、その下の coeffs のブロックも書き換えが必要であった。

incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
iincompressible/adjointOptimisationFoam/shapeOptimisation/motorBike

上記2つのケースは、デフォルトで並列数「20」の計算になっているが、これを見落とした。理由は、多並列計算ケースを抽出するのに、decomposeParDict をテキストサーチしていたのだが、これらのケースは、decomposeParDict でなく、decomposeParDict.20 というファイルで並列数が指定されていた為。

今回、上のケースは修正できていたが、下のケースを忘れていた

もっと速く！

上記ケースは、decomposeParDict で16が指定されているが、同梱のAllrunでは単体計算することになる。一方、Allrun-parallelも同梱されており、こちらを使えば並列計算となり、1時間以上の短縮は見込まれる。

その他気付いた点

foamyHexMesh

foamyHexMesh は永らくの間、開発が中断されていたと思われていたのが、v2412の記事で、わずかであるが変化があった…と記したが、今回は元通り（まともに使えない）に戻っている。計算システム依存性があったということかもしれない。

補足（SQL文、備忘録）

SQL-1

				
					select `ver_name` version,
 count(*) postcount,
 sum(`clockTime`)/3600 clockHr,
case when exe_system = 4 then 0.5* sum(`diskUsage`)/1000000
else  sum(`diskUsage`)/1000000 
end as du,
 sum(`clockTime`)/3600 ,
`name` exeSys,
`release_date`
 from `wp_of_tutorials`
JOIN wp_of_ver ON wp_of_tutorials.of_ver = wp_of_ver.id
JOIN wp_of_exe_system ON wp_of_tutorials.exe_system=wp_of_exe_system.id
group by `exe_system`, `of_ver`
order by `release_date`

SQL-4

				
					select `ver_name` version,
 category,
 count(*) postcount,
 sum(`diskUsage`)/1000,
 sum(`clockTime`)/3600 ,
`name` exeSys,
`release_date`,
case when exe_system = 4 then 0.5* sum(`diskUsage`)/1000000
else  sum(`diskUsage`)/1000000
end as du
 from `wp_of_tutorials`
 JOIN wp_of_ver ON wp_of_tutorials.of_ver = wp_of_ver.id
JOIN wp_of_exe_system ON wp_of_tutorials.exe_system=wp_of_exe_system.id
where wp_of_ver.id in (33, 34)
group by `exe_system`, `of_ver` ,`category`
order by `release_date`

SQL-5

				
					DROP TABLE IF EXISTS of_temp;
create table of_temp as

with old_data 
as( select category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `wp_of_tutorials` where of_ver in (33) and exe_system in (8))

select  new.category, new.solver, new.model, new.caseName, new.diskUsage, old.o_diskUsage, new.exeTime, old.o_exeTime , new.clockTime, old.o_clockTime 

from 
 wp_of_tutorials as new 
 inner join old_data old
  on new.category = old.o_category 
  and new.solver = old.o_solver 
  and new.model = old.o_model 
  and new.caseName = old.o_caseName 
where new.of_ver in (34)
order by new.category, new.solver, new.model, new.caseName 
;
select category, solver, model, caseName,  diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where clockTime > 0;

SQL-6

				
					DROP TABLE IF EXISTS of_temp;
create table of_temp as

with old_data 
as( select category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `wp_of_tutorials` where of_ver in (33) and exe_system in (8))

select  new.category, new.solver, new.model, new.caseName, new.diskUsage, old.o_diskUsage, new.exeTime, old.o_exeTime , new.clockTime, old.o_clockTime 

from 
 wp_of_tutorials as new 
 inner join old_data old
  on new.category = old.o_category 
  and new.solver = old.o_solver 
  and new.model = old.o_model 
  and new.caseName = old.o_caseName 
where new.of_ver in (34)
order by new.category, new.solver, new.model, new.caseName 
;
select category, solver, model, caseName,  diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where diskUsage > 0;

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

上部へスクロール